Skip to content

Do not mask the render error with "Parent has not been set" - #1587

Merged
zonky2 merged 1 commit into
hotfix/2.4.26from
hotfix/fix_render_fallback_without_parent
Aug 6, 2026
Merged

Do not mask the render error with "Parent has not been set"#1587
zonky2 merged 1 commit into
hotfix/2.4.26from
hotfix/fix_render_fallback_without_parent

Conversation

@zonky2

@zonky2 zonky2 commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

When rendering an attribute with a render setting failed, parseValue() retried with the default render settings and carried the parent over from the failing setting:

$objSettingsFallback = $this->getDefaultRenderSettings()->setParent($objSettings->getParent());

Render settings created on the fly have no parent - getDefaultRenderSettings() builds them without one - so getParent() threw "Parent has not been set" and replaced the real error with a misleading one. The FIXME in that line said exactly that.

Parsing an item without a render setting collection runs into this: parseValue() falls back to the default render settings, and any attribute failing to render (in the case at hand a text attribute holding an array, which makes the template raise "Array to string conversion") ends in a 500 that points at the parent instead of the actual problem.

The parent is now only carried over when the failing setting has one, and a failure of the fallback rendering re-throws the original exception instead of its follow-up error.

When rendering an attribute with a render setting failed, parseValue() retried with the
default render settings and carried the parent over from the failing setting:

    $objSettingsFallback = $this->getDefaultRenderSettings()->setParent($objSettings->getParent());

Render settings created on the fly have no parent - getDefaultRenderSettings() builds
them without one - so getParent() threw "Parent has not been set" and replaced the real
error with a misleading one. The FIXME in that line said exactly that.

Parsing an item without a render setting collection runs into this: parseValue() falls
back to the default render settings, and any attribute failing to render (in the case at
hand a text attribute holding an array, which makes the template raise "Array to string
conversion") ends in a 500 that points at the parent instead of the actual problem.

The parent is now only carried over when the failing setting has one, and a failure of
the fallback rendering re-throws the original exception instead of its follow-up error.
@zonky2 zonky2 added this to the 2.4.x milestone Aug 6, 2026
@zonky2 zonky2 self-assigned this Aug 6, 2026
@zonky2 zonky2 added the enhancement This issue is about an enhancement (aka new feature) label Aug 6, 2026
@zonky2
zonky2 merged commit da86eb6 into hotfix/2.4.26 Aug 6, 2026
4 checks passed
@zonky2
zonky2 deleted the hotfix/fix_render_fallback_without_parent branch August 6, 2026 12:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement This issue is about an enhancement (aka new feature)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant